Create a Filter from a string

I am trying to create a generic framework for updating documentation in DOORS.

As part of that framework I need a simple way of specifying a Filter from a string definition. Ideally I need a function that has this signature:

Filter createFromString(string filterDef)

This function would be able to recreate any Filter from the string returned by the following DXL function:

string stringOf(Module m, Filter f)

As far as I understand it, Filters are created against the current module, but I need to define the Filter in a parameters file which at the point of parsing, there is no current module. The following post goes someway to acheiving this, but I don't think it copes with all types of filter e,g. hasLinks

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014535081#77777777-0000-0000-0000-000014535573

 


TheNybbler - Thu Oct 09 09:54:16 EDT 2014

Re: Create a Filter from a string
Richard_Good - Thu Oct 09 14:26:41 EDT 2014

Try this one, had fun with the filter string thing years ago, no doubt Mathis's version is more clever/ shorter, but the attached worked for me - hope it helps!

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014436525&ps=25

 

Richard Good

Re: Create a Filter from a string
Mathias Mamsch - Mon Oct 13 13:38:33 EDT 2014

Just my two cents on this topic. I would not advise to try to use DXL code <-> filter in any script anymore...

When its about text -> Filter you should use a sane format (e.g. an xml representation) or write a small parser and create a filter from there.

When its about Filter -> text ... well maybe you do not need really need that. There should be only a few valid use cases for a function like this (e.g. some kind of export of DXL filters to a new DB).

Regards, Mathias

Re: Create a Filter from a string
TheNybbler - Tue Oct 14 04:22:54 EDT 2014

Richard_Good - Thu Oct 09 14:26:41 EDT 2014

Try this one, had fun with the filter string thing years ago, no doubt Mathis's version is more clever/ shorter, but the attached worked for me - hope it helps!

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014436525&ps=25

 

Richard Good

Thanks for posting this. It will help me a lot!

Re: Create a Filter from a string
TheNybbler - Tue Oct 14 04:32:28 EDT 2014

Mathias Mamsch - Mon Oct 13 13:38:33 EDT 2014

Just my two cents on this topic. I would not advise to try to use DXL code <-> filter in any script anymore...

When its about text -> Filter you should use a sane format (e.g. an xml representation) or write a small parser and create a filter from there.

When its about Filter -> text ... well maybe you do not need really need that. There should be only a few valid use cases for a function like this (e.g. some kind of export of DXL filters to a new DB).

Regards, Mathias

Hi Mathias,

 

Please could you explain why you would not advise doing this?

We are currently passing in a string to our DXL script in DXL format. This string then gets evaluated by our script, using the following code:

 

string code = "noError();\nModule m = addr_ " ((addr_ m) int) "\ncurrent=m\nFilter f = " filtStr "\n; set f;"  

eval_ code;         

 

The filterStr string will contain something like "attribute \"Object_Type\" == \"Cascaded Requirement\" || attribute \"Object_Type\" == \"Developed Requirement\" || attribute \"Object_Type\" == \"Derived Requirement\""

This filterStr is passed to the script at runtime.

Re: Create a Filter from a string
Richard_Good - Tue Oct 14 05:38:56 EDT 2014

Mathias Mamsch - Mon Oct 13 13:38:33 EDT 2014

Just my two cents on this topic. I would not advise to try to use DXL code <-> filter in any script anymore...

When its about text -> Filter you should use a sane format (e.g. an xml representation) or write a small parser and create a filter from there.

When its about Filter -> text ... well maybe you do not need really need that. There should be only a few valid use cases for a function like this (e.g. some kind of export of DXL filters to a new DB).

Regards, Mathias

@Mathias I am sure you are right, but we don't have the opportunity to redesign filters such that the individual parts and queries sit in an xml file rather than an 'insane' string ;-) . I find string to Filter and Filter to string functionality very useful when tweaking multi part complex filters which sometimes run to 20 or so individual parts and where you don't have the opportunity to introduce your own fiter parser right from the start. Rewriting multiple filter parts because the rubbish filter system ditches all but the final one applied to the view was very tedious and annoying this project removed a lot of the annoyance from doing this.

Re: Create a Filter from a string
Wolfgang Uhr - Tue Oct 14 09:44:52 EDT 2014

Richard_Good - Thu Oct 09 14:26:41 EDT 2014

Try this one, had fun with the filter string thing years ago, no doubt Mathis's version is more clever/ shorter, but the attached worked for me - hope it helps!

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014436525&ps=25

 

Richard Good

Hi

I think it is better to use the dxl-internal routines. Some months ago I've started a script to analyze a filter and this routines was designed to perform checks and create error messages and so on, but it can also be used to convert a filter to xml.

This are two files, AnalyzeFilter.inc is the basic routine set and the demo handles a set of and, or and not connected Column-Filters. But it is easy to add some routines for the other filters too. The analysation routines are complete.

Best regars

Wolfgang

 


Attachments

AnalyzeFilter.demo.dxl
AnalyzeFilter.inc

Re: Create a Filter from a string
Mathias Mamsch - Tue Oct 14 12:55:41 EDT 2014

Hi Richard,

looking at the code and rethinking I realized that writing a "small" parser is not so small after all and I can imagine that this library is indeed very helpful.

Regarding the reason why I would not advise to represent a filter as DXL code to save it somewhere (if you have the chance to choose your representation)  I just think one should use

  •     a stable representation (one that does not change with different DOORS versions)
  •     an intuitive representation (one that the non DXL programmer can intuitively understand)

The 'eval_' version has a couple of special problems:

  •     There are no sanity checks, so you will run into popup errors when an enum value you want to filter does not exist in the module or something like this. Implementing checks for those means again to parse the string ... So for a stable version of this code you will save no efforts ...
  • Running this code on an untrusted filter string will allow an attacker to execute any DXL code in the current user context. So imagine you save this string somewhere in a module, and a malicous user puts some bad DXL statements in there.

So the solutions by Wolfgang and Richard are a much better choice here ...  Still if you have the change to choose your representation - you should not use a DXL source code representation, even if you do not use eval.

Regards, Mathias